eDocs Home > BEA AquaLogic Data Services Platform 3.0 Documentation > Data Services Developer's Guide

How To Create Physical Data Services from Relational Tables and Views

You can use the the physical data service creation wizard to:

• Select relational as the Data Source type.
• Select a data source from available relational sources.
• Choose a Database Type. For example, ALDSP samples use the Pointbase database.
• Select the Table and Views option.

Topics 

Setting Up the Physical Data Service Creation Wizard

Physical data services are created using a wizard.

Physical Data Service Creation Wizard

Starting the Wizard

To start the physical data service creation wizard:

1. Right-click on your dataspace project or any folder in your project.
2. Choose New > Physical Data Service

Creating a New Physical Data Service

Setting Up the Import Wizard for Relational Objects

When importing a relational object available options include the ability to:

1. Set a location for your new data service to be saved within your project.
2. Select a data source from the dropdown listbox.
3. Select the database type for the selected source (PointBase for the sample RDBMS) from the dropdown listbox.
4. Select among the relational source types listed in the following table. 

Types of available relational data sources

Selecting SQL Table and View Objects for Import

To create a physical data service based on a relational table or view:

1. Select the Tables and Views option
2. Click Next.  

A list of available database table and view SQL objects appears.

Objects are grouped based on the relational data sources catalog and/or schema.

In the example of an RTLCUSTOMER catalog, the ADDRESS and CUSTOMER tables both become physical data services.

Database-specific Catalog and Schema Considerations

Simply check the desired objects or their container, which will select all enclosed tables or views.

Table and View Objects Selected for Import

If you click on an individual object such as ADDRESS or CUSTOMER, information describing the database's primary key(s), column name, type and nullability appears. For example the CUSTOMER table contains a CUSTOMER_ID field of type VARCHAR. That column is not nullable, meaning that it must be supplied with any updates.

Physical Data Service Properties

Setting Properties for New Data Service Operations

Each new entity data service is created with a Read function that contains all the metadata elements identified during data service creation. It can be thought of as comparable to the following construct in the relational world:

select * from <table>

Use the Properties dialog to:

• Optionally modify the operation name.

• Set the Public option (check if you want your function to be available to client applications).
• Set the kind of operation (in some cases only Read will be available).
• Set the Primary option (check if you want your function to be the primary of its type).

  In some cases this option may not be available.

• Select a common XML namespace for the entire data service or individual target namespaces for specific operations.
• Set the target namespace.

The root element, which is read-only, is also displayed.

Initially the root element name matches the name of the data service.

Setting Properties for New Data Service Functions

Default Naming Conventions 

There are several default naming conventions associated with new data services:

• When a table, view, or other data source object is the source for a data service, the nominated name is wherever possible the same as the source object name. In some cases, however, names are adjusted to conform with XML naming conventions.

• Initially the root element name matches the name of the data service.

  XML Name Conversion Considerations

Verifying Data Service Composition

On the Review New Data Service(s) page you can set, confirm or, optionally, change suggested data service names depending on the type of physical data service you are creating.

Default Physical Data Service Names 

The nominated name for a new data service is, wherever possible, the same as the source object name. In some cases, however, names are adjusted to conform with XML naming conventions.

XML Name Conversion Considerations

About Automatic Data Service Name Changes

Name conflicts occur when there is a data service of the same name present in the target directory. Name conflicts are highlighted in red.

There are several situations where you will need to change the name of your data service:

• There already is a data service of the same name in your application.
• You are trying to create multiple data services with the same name.

Data services always have the file extension:

.ds

Database-specific Catalog and Schema Considerations

Database vendors variously support database catalogs and schemas.

Vendor Support for Catalog and Schema Objects

XML Name Conversion Considerations

When a source name is encountered that does not fit within XML naming conventions, default generated names are converted according to rules described by the SQLX standard. Generally speaking, an invalid XML name character is replaced by its hexadecimal escape sequence (having the form xUUUU).

For additional details see section 9.1 of the W3C draft version of this standard:

Contact BEA | Feedback | Privacy | (c) 2008 BEA Systems